[SYNCOPE-1981] Search audit events by who#1438
Conversation
ilgrosso
left a comment
ilgrosso
left a comment
There was a problem hiding this comment.
This PR is proposing to add the capability to search audit events by who, e.g. by the administrator that was logged as the requester for the action that was logged as audit entry.
I believe this is a nice addition but it will require a different issue on JIRA.
This because SYNCOPE-1978 is instead asking to restore the possibility to match audit events by username, e.g. to look for users whose payload was logged for the audit entry - as opposite as the current capability to look for such users only by their key.
ozimakov
changed the title
|
Hi @ilgrosso |
Add the ability to search audit events by the principal that performed them. A new "who" query parameter on AuditQuery matches the AuditEvent.who column by exact value and may be repeated to match any of the given values (OR), composing with the existing audit search filters. The filter is threaded through AuditServiceImpl, AuditLogic and the AuditEventDAO interface and all of its implementations (JPA, Neo4j, Elasticsearch, OpenSearch). Values are bound as query parameters (SQL/Cypher) or passed as structured term queries (Elasticsearch/OpenSearch), so there is no injection surface. Covered by new integration tests in AuditITCase.
2 participants
SYNCOPE-1981
What
Adds the ability to search audit events by the principal that performed them. A new
whoquery parameter onAuditQuerymatches theAuditEvent.whocolumn by exact value and may be repeated to match any of the given values (OR):?who=jsmith?who=jsmith&who=adminIt composes (AND) with the existing audit search filters (
entityKey,type,category,op,outcome,before/after).Why
There is no way to answer "what did administrator X do". This is useful to retrieve all actions performed by a given principal — in particular when that account has since been deleted and its entity key is no longer available. Syncope 3.0 allowed an approximation by abusing
entityKey=<username>; the 4.0 audit refactor correctly madeentityKeymatch only the affected entity's UUID, removing that side effect.Implementation
The filter is threaded through
AuditServiceImpl→AuditLogic→ theAuditEventDAOinterface and all of its implementations: JPA, Neo4j, Elasticsearch and OpenSearch.who IN (?, ...)with bound parameters;n.who IN $whowith a bound list parameter;termquery per value, OR-ed viabool/should.All values are bound as query parameters (SQL/Cypher) or passed as structured term queries (Elasticsearch/OpenSearch), so there is no injection surface.
Tests
New integration tests in
AuditITCasecover exact match, multiple values (OR), no-match, and that the match is exact (a*is treated literally, not as a wildcard), composed with the other filters. Manually verified end-to-end against embedded PostgreSQL and Neo4j.